Coordination via Interaction Constraints I: 

Local Logic 




Jose Proenca* 

cwi, 

Science Park 123, 
1098 XG Amsterdam, The Netherlands 



dave . clarke@cs .kuleuven.be 




Wegner describes coordination as constrained interaction. We take this approach literally and define 
a coordination model based on interaction constraints and partial, iterative and interactive constraint 
satisfaction. Our model captures behaviour described in terms of synchronisation and data flow 
constraints, plus various modes of interaction with the outside world provided by external constraint 
symbols, on-the-fly constraint generation, and coordination variables. Underlying our approach is 
an engine performing (partial) constraint satisfaction of the sets of constraints. Our model extends 
previous work on three counts: firstly, a more advanced notion of external interaction is offered; 
secondly, our approach enables local satisfaction of constraints with appropriate partial solutions, 
avoiding global synchronisation over the entire constraints set; and, as a consequence, constraint 
satisfaction can finally occur concurrently, and multiple parts of a set of constraints can be solved 
and interact with the outside world in an asynchronous manner, unless synchronisation is required by 
the constraints. 

This paper describes the underlying logic, which enables a notion of local solution, and relates 
this logic to the more global approach of our previous work based on classical logic. 

1 Introduction 

Coordination models and languages [15] address the complexity of systems of concurrent, distributed, 
mobile and heterogeneous components, by separating the parts that perform the computation (the com- 
ponents) from the parts that "glue" these components together. The glue code offers a layer between 
components to intercept, modify, redirect, synchronise communication among components, and to facil- 
itate monitoring and managing their resource usage, typically separate from the resources themselves. 

Wegner describes coordination as constrained interaction [16]. We take this approach literally and 
represent coordination using constraints. Specifically, we take the view that a component connector 
specifies a (series of) constraint satisfaction problems, and that valid interaction between a connector and 
its environment corresponds to the solutions of such constraints. 

In previous work [5] we took the channel-based coordination model Reo [1], extracted constraints 
underlying each channel and their composition, and formulated behaviour as a constraint satisfaction 
problem. There we identified that interaction consisted of two phases: solving and updating constraints. 
Behaviour depends upon the current state. The semantics were described per-state in a series of rounds. 
Behaviour in a particular step is phrased in terms of synchronisation and data flow constraints, which 
describe the synchronisation and the data flow possibilities of participating ports. Dataflow on the end 
of a channel occurs when a single datum is passed through that end. Within a particular round data flow 
may occur on some number of ends; this is equated with the notion of synchrony. The constraints were 
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based on a synchronisation and a data flow variable for each port. Splitting the constraints into syn- 
chronisation and data flow constraints is very natural, and it closely resembles the constraint automata 
model [3]. These constraints are solved during the solving phase. Evolution over time is captured by 
incorporating state information into the constraints, and updating the state information between solving 
phases. Stronger motivation for the use of constraint-based techniques for the Reo coordination model 
can be found in our previous work [5]. By abstracting from the channels metaphor and using only the 
constraints, the implementation is free to optimise constraints, eliminating costly infrastructure, such 
as unnecessary channels. Furthermore, constraint- solving techniques are well studied in the literature, 
and there are heuristics to search efficiently for solution, offering significant improvement of other mod- 
els underlying Reo implementations. To increase the expressiveness and usefulness of the model, we 
added external state variables, external function symbols and external predicates to the model. These 
external symbols enable modelling of a wider range of primitives whose behaviour cannot expressed by 
constraints, either because the internal constraint language is not expressive enough, or to wrap external 
entities, such as those with externally maintained state. The constraint satisfaction process was extended 
with means for interacting with external entities to resolve external function symbols and predicates. 
In this paper, we make three major contributions to the model: 

Partiality Firstly, we allow solutions for the constraints and the set of known predicates and functions 
to be partial [4]. We introduce a minimal notion of partial solution which admits solutions only on 
relevant parts (variables) of a connector. External symbols that are only discovered on-the-fly are 
more faithfully modelled in a partial setting. 

Locality Secondly, we assume a do nothing solution for the constraints of each primitive exists, where 
no data is communicated. This assumption, in combination with partiality, allows certain solutions 
for part of a connector to be consistently extended to solutions for the full connector. Furthermore, 
our notion of locality enables independent parts of the connector to evolve concurrently. 

Interaction Thirdly, we formalise the constraint satisfaction process with respect to the interaction with 
the external world, and we introduce external constraint symbols. These can be seen as lazy 
constraints, which are only processed by the engine on demand, by consulting an external source. 
These can be used to represent, for example, a stream of possible choices, which are requested on 
demand, such as the pages of different flight options available on an airline booking web page. 

Organization The next section gives an overview of the approach taken in this paper, providing a 
global picture and relating the different semantics we present for our constraints. The rest of the paper is 
divided into two main parts. The first part describes how constraints are defined, and defines four different 
semantics for variants of the constraint language and relates them. We present a classical semantics in § 3 
and two partial semantics in § 4, and exploit possible concurrency by allowing local solutions in § 5. The 
second part introduces a constraint-based engine to perform the actual coordination, search and applying 
solutions for the constraints. We describe stateful primitives in § 6, and add interaction in § 7. We give 
some conclusions about this work in § 8. 

2 Coordination = Scheduling + Data Flow 

We view coordination as a constraint satisfaction problem, where solutions for the constraints yield how 
data should be communicated among components. More specifically, solutions to the constraints de- 
scribe where and which data flow. Synchronisation variables describe the where, and data flow variables 
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describe the which. With respect to our previous work [5], we move from a classical semantics to a local 
semantics, where solutions address only part of the connector, as only a relevant subset of the variables 
of the constraints are required for solutions. We do this transformation for classical to local semantics in 
a stepwise manner, distinguishing four different semantics that yield different notions of valid solution 
a, mapping synchronisation and data flow variables to appropriate values: 

Classical semantics 

• a are always total (for the variables of the connector under consideration); 

• an explicit value NO-FLOW is added to the data domain to represent the data value when there 
is no data flow; 

• an explicit flow axiom is added to constraints to ensure the proper relationship between syn- 
chronisation variables and data flow variables; and 

• constraints are solved globally across the entire 'connector' . 

Partial semantics 

• a may be partial, not binding all variables in a constraint; 

• the NO-FLOW value is removed and modelled by leaving the data flow variable undefined; and 

• as the previous flow axiom is no longer expressible, the relationship between synchronisation 
and data flow variables is established by a new meta-flow axiom, which acts after constraints 
have been solved to filter invalid solutions. 

Simple semantics 

• a is partial, and the semantics is such that only certain "minimal" solutions, which define 
only the necessary variables, are found; and 

• the meta-flow axiom is expressible in this logic, so a simple flow axiom can again be added 
to the constraints. 

Local semantics 

• formula? are partitioned into blocks, connected via shared variables; 

• each block is required to always admit a do nothing solution; 

• some solutions in a block can be found without looking at its neighbours, whenever there is 
no-flow on its boundary synchronisation variables; 

• two or more such solutions are locally compatible; 

• blocks can be merged in order to find more solutions, in collaboration, when existing solu- 
tions do not ensure the no-flow condition over the boundary synchronisation variables; and 

• the search space underlying constraints is smaller than in the previous semantics, and there 
is a high degree of locality and concurrency. 

We present formal embeddings between these logics, with respect to solutions that obey the various 
(meta-) flow axioms (linking solutions for synchronisation and data flow variables). We call such solu- 
tions firings. The first step is from a classical to a partial semantics. The number of solutions increases, 
as new (smaller) solutions also become valid. We then move to a simple semantics to regain an express- 
ible flow axiom, where only some "minimal" partial solutions are accepted. In the last step we present 
a local semantics, where we avoid the need to inspect even more constraints, namely, we avoid visiting 
constraints added conjunctively to the system, by introducing some requirements on solutions to blocks 
of constraints. 



20 



Coordination via Interaction Constraints 



3 Coordination via Constraint Satisfaction 

In previous work we described coordination in terms of constraint satisfaction. The main problem with 
that approach is that the constraints needed to be solved globally, which means that it is not scalable 
as the basis of an engine for coordination. In this section, we adapt the underlying logic and notion 
of solution to increase the amount of available locality and concurrency in the constraints. Firstly, we 
move from the standard classical interpretation of the logic to a partial interpretation. This offers some 
improvement, but the solutions of a formula need to be filtered using a semantic variant of the flow 
axiom, which is undesirable because filtering them out during the constraint satisfaction process could be 
significantly faster. We improve on this situation by introducing a simpler notion of solution for formulas, 
requiring only relevant variables to be assigned. This approach avoids post hoc filtering of solutions. 
Unfortunately, even simple solutions still require more or less global constraint satisfaction. Although 
it is the case that many constraints may correspond to no behaviour within parts of the connector — 
indeed all constraints admit such solutions — , the constraint satisfier must still visit the constraints to 
determine this fact. In the final variant, we simply assume that the no behaviour solution can be chosen 
for any constraint not visited by the constraint solver, and thus the constraint solver can find solutions to 
constraints without actually visiting all constraints. This means that more concurrency is available and 
different parts of the implicit constraint graph can be solved independently and concurrently. 

We start by motivating our work via an example, and we then describe the classical approach to 
constraint satisfaction and its problems, before gradually refining our underlying logic to a be more 
amenable to scalable satisfaction. 

3.1 Coordination of a complex data generator 

We introduce a motivating example, depicted in Figure 1 , where a Complex Data Generator ( CDG ) sends 
data to Client. Data communication is controlled via a coordinating connector. The connector consists 
of a set of composed coordination building blocks, each with some associated constraints describing 
their behavioural possibilities. We call these building blocks simply primitives. The CDG and the Client 
are also primitives, and play the same coordination game by providing some constraints reflecting their 
intentions to read or write data. 




Figure 1: Network of constraints: coordinating a complex data generator. 

Figure 1 uses a graphical notation to depict how the different primitives are connected. Each box 
represents a primitive with some associated constraints, connected to each other via shared variables. 
For example, the CDG shares variable a with FIFO\, Filter(p), and SyncDrain, indicating that the same 
data flows through the lines connecting theses primitives in the figure. The arrows represent the direction 
of data flow, thus the value of a is given by CDG and further constrained by the other attached primitives. 
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Most of the coordination primitives are channels from the Reo coordination language [1]. Previous 
work [5] described a constraint-based approach to modelling Reo networks. Here we forego the graphical 
representation to emphasise the idea that a coordinating connector can be seen as a soup of constraints 
linked by shared variables. One optimisation we immediately employ is using the same name for ends 
which are connected by synchronous channels or replicators. 1 Note that in the original description of 
Reo, nodes act both as mergers and replicators. This behaviour can be emulated using merger and 
replicator primitives, as we have done. The result is a simpler notion of node, a 1:1 node which both 
synchronises and copies data from the output port to the input port. Primitives act as constraint providers, 
which are combined until they reach a consensus regarding where and which data will be communicated. 
Only then a possible communication of data takes place, and the primitives update their constraints. 

In the particular case of the example in Figure 1, there is a complex data generator (CDG) that 
can write one of several possible values, a filter that can only receive (and send) data if it validates a 
given predicate p, a component (User approval) that approves values based on interaction with a user, a 
destination client that receives the final result, and some other primitives that impose further constraints. 
We will come back to this example after introducing some basic notions about the constraints. 

Notation We write 3)ata to denote a global set of possible data that can flow on the network. NO-FLOW 
is a special constant not in *2)ata that represents no data flow. denotes a set of synchronisation 
variables over {tt,ff}, 3£ = {x | x G JT} a set of data flow variables over 3>ata U {NO-FLOW}, 2? 
a set of predicate symbols, and J? a set of function symbols such that Qiata C # '. (Actually, 3>ata is 
the Herbrand universe over function symbols J^.) We use the following variables to range over various 
domains: x G SC , x G 9£ , f G and p G J 2 . Recall that synchronisation variables and data flow 
variables JT are intimately related, as one describes whether data flows and the other describes what the 
data is. 

3.2 Classical Semantics 

Consider the logic with the following syntax of formulas (iff) and terms (t): 

Y "= tt | x | yiAV2 | I p(t u ...,t n ) 
t ::= x | f(t\,...,t n ) 

tt is true. We assume that one of the internal predicates in & is equality, which is denoted using 
the standard infix notation t\ = ti. The other logical connectives can be encoded as usual: ff = ->tt; 

Wi V^2 = " , (^^i A-1I//2); Yi —> Y2 = ^¥i V V2; and ^¥2={Wi —> ¥2) ^(¥2 —> ¥i)- Constraints can 
be easily extended with an existential quantifier, provided that it does not appear in a negative position, 
or alternatively, that it is used only at the top level. 

The semantics is based on a relation <j, J* \=c where a is a total map from 3£ to {tt,ff} and 
from % to Qata U {NO-FLOW}, and J is an arity-indexed total map from & n x & n to {tt,ff}, for 
each n > 0, where & n is the set of all predicate symbols of arity n, S? is the set of all possible ground 
terms (terms with no variables) plus the constant NO-FLOW. The semantics is defined by a satisfaction 
relation \=c defined as follows. The function Val a replaces all variables v by cr(v), and we assume that 
Val(j(f(h, . . .,*„)) = NO-FLOW whenever t t = NO-FLOW, for some i G \..n. 



Semantically, this view of synchronous channels and replicators is valid. 
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Definition 1 (Classical Satisfaction) 



0,J?\= C X 

o,J? \= c yi Ay/2 
o,S \=c^¥ 

\= c p(h,..., 



always 

iff o(x) = tt 

iff a, J? \= c Vi and a, J \= c ¥2 
iff o,J?^y 

iff p(Val a (h),. . . , Val a (t n )) wtte/ 



The following axiom relates synchronisation and data flow variables, stating that a synchronisation 
variable being set to f f corresponds to the corresponding data flow being NO -FLOW. 



Axiom 1 (Flow Axiom) 



nx x = NO-FLOW 



(flow axiom) 



We introduced this in our previous approach for coordination via constraints [5]. Every pair of 
variables, x and x, is expected to obey this axiom. Write FA(x) for the flow axiom for variables x,x and 
FA(X) for the conjunction f\ xeX FA(x). Also write fv(\j/) f° r tne f ree variables of y/\ i.e., variables from 
SC and X that occur in \\f. 

Definition 2 (Classical Firing) A solution o to constraint \jf which satisfies the meta-flow axiom is 
called a classical firing. That is, O is a classical firing for \ff if and only ifo, J? \=c ¥ AFA(Jv(y))- ^ 

Example 1 Recall the example from § 3.1. We define the constraints for each primitive in Table 1. The 
client does not impose any constraints on the input data (tt), and the F1F0\ primitive is empty so its 
constraints only say that no data can be output. UserAppr is an external predicate symbol, which must 
be resolved using external interaction (See § 7.1). Later we extend some of these constraints to capture 
the notion of state and interaction (see Table 2). The behaviour of the full system is given by the firings 
for the conjunction of all constraints. 



Primitive 

[ cdg ~~y 

c ► [ Client J 



User approval 



a ^ SyncDrain c 



Filter(p) y . c 
a^ [ FIFO l ~y b 



¥1 

¥2 

¥3 
¥4 
¥5 

¥e 
¥1 



Constraint 

a ^ (a = d^Va = &2^J a = d^) 
tt 

c — > UserAppr(c) 
a <-> c 

c->dAc-> (p(c) Aa = c) 
A (a A p(a)) — > c 

^b 



Table 1: List of primitives and their associated constraints, where di,d2,d3 6 QJata. 
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Consider the Filter (p) primitive in Table 1. The flow axiom is given by FA(a,c). The constraint 
c — > a can be read as: if there is data flowing on c, then there must also be data flowing on a. The second 
part, c — > (p(c) Aa = c), says that when there is data flowing on c its value must validate the predicate p, 
and data flowing in a and c must be the same. Finally, the third part (a A p{d)) — > c states that data that 
validates the predicate p cannot be lost, i.e., flow on a but not on c. A classical firing for the interpretation 

is {a i— > tt,c i— > tt,a i— > d,c^-> d} whenever ci G 3>ata is such that h> tt £ /. The assignment 
{c i ^ tt,c I— > NO-FLOW} is not a classical firing because it violates the flow axiom, and because it is not 
a total map (it refers to neither a nor a). 



4 Partiality 

The first step towards increasing the amount of available concurrency and the scalability of our approach 
is to make the logic partial. This means that solutions no longer need to be total, so for some x G 5£ 
or x G 3£, o{x) or a(x) may not be defined. In addition, we drop the NO-FLOW value and so a(x) may 
either map to a value from Stata or be undefined. The semantics is defined by a satisfaction relation \=p 
and a dissatisfaction relation =\p defined below. These state, respectively, when a formula is definite true 
or definitely false. Partiality is introduced in either the clause for x or for p(t\, . . .,t n ), whenever some 
variable is not defined in a. An assignment a now is a partial map from synchronisation variables to 
{tt,ff}, and from data flow variables to *2)ata. Similarly, an interpretation is now an arity-indexed 
family of partial map from J 2 ,, x S? n to {tt,f f }, where ST is the set of all possible ground terms, and 
Val a (f(t\,. . .,*„)) = -L whenever Val a (ti) = _L, for some i G l..n. We use _L to indicate when such a map 
is undefined. 



Definition 3 (Partial Satisfaction) 



<J, \=p tt always 

o,J^\= P x iff a(x) = tt 

a, J \= P y/i A y/2 iff a, J \= P \ff\ and a, J \= P yi 

a,^\= P ->Y iff o,f=\p-y 

0,S\= P p(ti,...,tn) iff p(Val a (h),...,Val a (t n )) ^ tt G 



a, J =\ P x 

a, J Hp Yi A ¥2 
<j,j?=\p^\I/ 

o,S=\ P p(ti,...,t n ) 



iff a(x) = ff 

iff o,S=\p Wi ora,J?^ P y/2 

iff e,J?hpY 

iff p(Val a (ti), . . . , Val a {t n )) i— > f f € 



Lemma 1 If o and J? are total, then either o \J? \=p Y or ° Hp W> but it is never undefined. 

We need to adapt the flow axiom as it refers explicitly to NO-FLOW, which is no longer available. The 
obvious change would be to replace NO-FLOW by partiality, giving (semantically) <j(x) = if <^=^ a(x) = 
_L. But we can do better, permitting a(x) = _L to also represent no data flow. In addition, it is feasible 
that a(x) = tt with a(x) = _L is a valid combination, to cover the case where the actual value of the 
data does not matter. Together, these give the following meta-flow axiom, which is a semantic and not 
syntactic condition. 
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Axiom 2 (Meta-Flow Axiom) An assignment a obeys the meta-flow axiom whenever for all x £ S£ : 

<j(x) / _L ==>- o(x) = tt 

Write MFA(a) whenever o obeys the meta-flow axiom. 

The following table gives all solutions to the meta-flow axiom: 





possible 


forbidden 


X 


tt 


tt ff 


_L 


ff _L 


X 


d 


_L _L 


_L 


d d 



For comparison, the following table gives the solutions for the flow axiom: 





possible 


forbidden 


X 


tt ff 


tt ff 


X 


d NO-FLOW 


NO-FLOW d 



Definition 4 (Partial Firing) A partial solution o to a constraint y that satisfies the meta-flow axiom is 
called a partial firing. That is, whenever a,J^\=py and MFA{o). < 

Consider again the constraints of the Filter (p) primitive in Table 1. A possible firing for it is {a h-> 
tt,CH > ff ,a i— ► d,c i— > NO-FLOW} where d £ Slata does not validate the predicate p. The equivalent 
partial solution can be obtained by replacing NO-FLOW by J_. Therefore, {a ^ tt,c i-> ff ,a <— ► d} is 
also a partial firing, whenever p(d) does not hold. Note also that {c <— > f f }, J 1 \=p a — > c holds in the 
partial setting, yet {c ff}, J? \= c a — > c does not hold in the classical setting, because the classical 
satisfaction requires the solutions to be total mappings of all variables involved. 



4.1 Embeddings: Classical <-> Partial 

We can move from an explicit representation of no-flow, namely a(x) = ft and a(x) = NO-FLOW, to 
an implicit representation using partiality, namely either a(x) = _L and a(x) = _L or a(x) = f f , which 
means that the constraint solver need not find a value for x or x. 



Lemma 2 (Classical to Partial) Let \\fbea constraint where NO-FLOW does not occur in y, and o be an 

assignment where dom(a) =fv(\\f). We write J"° to represent the interpretation obtained by replacing 
in J? the constant NO-FLOW by _L. If o is a classical firing for y and the interpretation .J? , then a° is a 
partial firing for y and the interpretation where o° is defined as follows: 



a°(x) = a(x) 

_L, if a (x) = NO-FLOW 
a(x), otherwise 



(T°(x) 



Proof Assume that o,J \= c yAFA(fv(y)). Then (1) c,J? \= c y and (2) o,J \= c FA(fv{y)). It 
can be seen by straightforward induction that (1) implies that a°,/° \=p y, because maps the same 
values than J 1 after replacing NO-FLOW by _L, and a° is defined for all free synchronisation variables. 
Since (2) holds for every x efv(y) and dom(a°) n SIC = dom(a) n 3£ = fv(y) n SC , we can safely 
conclude that MFA(a°): when a°(x) / tt then a°(x) = a(x) = f f , implying by the flow axiom that 
a(x) = NO-FLOW, where we conclude that a°(x) = _L (and the meta-flow axiom holds). □ 
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Lemma 3 (Partial to Classical) If a is a partial firing for y and for a total interpretation J? ', then 
is a classical firing for y and for an interpretation J*^ , where ^ results from replacing _L by NO-FLOW 
in , and is defined as follows: 

a\x) = a(x), ifa(x)^± 
o\x) = ff , ifo{x) = _L 

o-f(x) = a(x), ifa(x)^± 

C^(x) = NO-FLOW, ifo{x) = _L and o{x) / tt 

o\x) = 42, ifo(x) = _L and o(x) = tt 

Proof Assume that (1) o,J^ \= P y and (2) MFA(o). Note that a t is total, J rt is total, and a C a 1 ". It 
can be seen by Lemma 1 that a C a 1 " and (1) imply a 1 , \= c y. We snow that a 1 ", J^ 1 " \= c FA(fv(y)) 
by considering all possible cases, (i) If a(x) / _L then o^(x) = a(x), and from (2) we conclude that 
a\x) = o{x) = tt. (ii) If o{x) = _L and a{x) = tt, then a\x) = 42 and a f (x) = tt. (iii) If a(x) = _L 
and o{x) / tt, then o^{x) = f f and o\x) = NO-FLOW. □ 



4.2 Inexpressibility of Meta-Flow Axiom 

Unfortunately, the meta-flow axiom is not expressible in partial logic. A consequence of this is that if 
partial logic is used as the constraint language, solutions may be found which do not satisfy this axiom; 
such solutions subsequently need to be filtered after performing constraint satisfaction, which clearly is 
not ideal, as the constraint engine would need to continue to find a real solution, having wasted time 
finding this non-solution. 

The following lemma will help prove that the meta-flow axiom is not expressible. 

Lemma 4 If o,.y \= P y and a C a', then a', J \= P y. 

Proof. By straightforward induction on y. □ 
Lemma 5 No formula y exists such that a, J* |=p y if and only ifMFAio). 

Proof. Assume that yMFA is such a formula over variables {x,x}. Then for a = {x f f } we have that 
a, J? \=p yMFA- Now a C a' = {x i-> f f ,£i— >• 42}. Hence by Lemma 4, we have that a', J 1 \= P yMFA- 
But a' does not satisfy the meta-flow axiom. Contradiction. □ 



4.3 Simple Logic 

Using partial logic as the basis of a coordination engine is not ideal, as constraint satisfaction for this 
logic could find solutions which do not satisfy the meta-flow axiom (due to Lemma 5). Such solutions 
would need to be filtered in a post-processing phase, resulting in an undesirable overhead. 

We resolve this problem by modifying the semantics so that only certain 'minimal' solutions are 
found. These solutions define only the necessary variables — which has the consequence that the con- 
straint solver needs only to satisfy variables mentioned in the (relevant branch of a) constraint. We extend 
also the syntax of formulas by distinguishing two kinds of conjunctions. The overlapping conjunction 
(A) of two constraints accepts two compatible solutions and joins them together, while an additive con- 
junction (A) accepts only solutions which satisfy both constraints. Both kinds of conjunction are present, 
firstly, to talk about the joining of solutions for (partially) independent parts of a connector (overlapping 
conjunction), and to enforce overarching constraints, such as the flow axiom (additive conjunction). The 
semantics for the logic is formalised in Definition 5. In this logic, the meta-flow axiom is expressible. 
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Definition 5 (Simple satisfaction) We define inductively a simple satisfaction relation a, \=s Y an d 
a simple disatisfaction relation (J,^=\sW> where the assignment a and the interpretation J' may he 
partial. 

0, J^|=stt always 
{ [jc i— ► tt] }, J 1 \=sx always 

<7i U a 2 , J^\=sYi A Y2 iff a\,J \= s Yi and a 2 , J \= s Y2 and a { — a 2 
a,J^\=sYi^Y2 W \=sYi ando,J? \= s \l/ 2 

a,y\=s^Y W e,y=\sY 

<?,y\=sP(h,---,t n ) ff p(Val a (h), . . . ,Val a (t n )) i-> tt G J anddom{p) = fv(p(h . . . ,t n )) 

{[x 1— > f f ]}, ^=|sx a/way* 

a, J?=\sW\ A ^2 # /or a# <7i , a 2 s.?. ai ^ a 2 ara<i a = ai U a 2 

we Ziave (7i , =\s Vi or a 2, ^ V2 

o,y=\s^Y iff (J,y\=s¥ 

o,S=\sp(ti,...,t n ) iff p(Val a (h), . . . ,Val a (t n )) ff £ ,Y and dom(a) = fv(p(h . . . ,t n )) 
where <Ji ^ a 2 = Vx £ dom(c\) C\dom(C2)-G\ (x) = a 2 (x) 



The additive conjunction A of and 1//2 is satisfied by a if a satisfies both Yi an d y/2- The over- 
lapping conjunction A is more relaxed, and simply merges any pair of solutions for and Y2 that do 
not contradict each other. For the constraints of the primitives, the conjunctions that appear in a positive 
position are regarded as overlapping conjunctions (A), while the conjunctions that appear in a negative 
position are regarded as additive conjunctions (A). 2 As a consequence, the rule for a, / A Y2 is 

only used when applying the flow axiom, as we will soon see, and the rule for o, ^ =|s Xj/i A Xj/2 is present 
mainly for the completeness of the definition. 



Notation In the following we write xy s to represent the constraints obtained by replacing all conjunc- 
tions in y in negative positions by A, and we write Xj/ P to represent the constraints obtained by replacing 
all occurrences of A in xjf by A. We also encode xj/\ - Y2 as -<(-i Xj/\ A -iXj/2). 



When specifying constraints in simple logic, we never use — V — in a positive position, which would 
correspond to — ■(— ■ — A— ■ — ), as this means satisfying the clause <7, J? =|s Xj/\ A Xj/2 in order to find a 
given assignment. Therefore we do not require the use of universal quantification over solution sets. 
In the partial satisfaction relation, we define how to verify that a given pair a, satisfies a constraint. 
The simple satisfaction relation aims at constructing a such that the pair o,J? satisfies the constraints. 
Assuming the universal quantifier is never used, we believe that the simple satisfaction relation describes 
a constructive process to obtain a solution that is not more complex than searching for a solution in partial 
logic. Note that we still lack experimental verification of this intuition. 

The following axiom is the syntactic counterpart of the meta-flow axiom, modified slightly to be 
laxer about what it considers to be a solution (namely allowing data flow variable to be satisfied, without 
requiring that the corresponding synchronisation variable are defined). 



2 A positive position is inside the scope of an even number of negations, and a negative position is inside the scope of an odd 
number of negations. For example, in (-i(a/\-ib)) A c, a is in a negative position, while b and c are in a positive position. 
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Definition 6 (Simple Flow Axiom) 

SFA{x) = tt v x y -, x V (xAx = x) V £=£ (simple flow axiom) 

< 

We write SFA(X) for the conjunction f\ xeX SFA(x). We also write SFA(\{f) as a shorthand for 
SFA(fv(y)). 

Lemma 6 <7,J^ ^5 SFA(x) if and only if a p satisfies the meta-flow axiom, where a p extends a as 
follows: 

a p = au{x i-> tt 1 3c€ dom(a)} 

Proof. Wehave0,=y |=stt; {x i-> tt}, |= s x; {x i-> f f }, <y |= 5 — ijc; {x i-> tt,x^ ^ ^ 5 x Ax = x; 
and {ih ;}, \= s x = x, for an arbitrary ground term t, and no other a. Extending o to o p we obtain 
precisely the solutions to the meta-flow axiom. □ 
Observe that simple logic clearly does not preserve classical or even partial equivalences, as tt V x Y. 
-x V (ia£= x) Y. x = x =c tt, classically, but this is not the case in simple logic. 

Definition 7 (Simple Firing) 

An assignment a is called a simple firing whenever a,J^\=s yASFA(\ff). < 

Note that the simple flow axiom differs from the meta-flow axiom because it also accepts solutions 
where x is defined, but x is not. This is because the simple flow axiom is designed to filter from a set 
of minimal solutions (i.e., solutions in the simple logic), while the meta-flow axiom is designed to filter 
good solutions from all solutions the constraint engine finds, namely, the ones that include additional 
assignments to make the flow axiom hold. As a consequence, the assignment {ah d} is a simple firing 
for the formula d=d, and the assignment {a^ d,a^ tt} is a partial firing for the same formula, but 
not the other way around. 

With simple logic we can check a formula to ensure that all of its solutions satisfy the meta-flow 
axiom. This means that we do not need to filter solutions to such a constraint. Furthermore, as the simple 
flow axiom is preserved through composition (A), we are guaranteed to have simple firings without 
having to perform a post hoc filter phase. 

Note that implication in simple logic does not have the exact same meaning as in the other logics. 
c — > a, whenever in a positive position, is regarded in simple logic as -i(cA-ia), which has only two 
firings: {c ^ ff } and {a ^ tt}. The union of these two firings is not a simple firing because it is 
not "minimal enough". That is, the resulting union is not satisfied by the simple satisfaction relation 
because it contains too many elements. Recall the constraints of the Filter (p) in Table 1, and let d be 
such that p(d) does not hold. The assignment {a <— > tt,c 1— > ff ,a 1— > d} is both a partial and a simple 
firing. However, {z •— ► tt,a i-> tt,c i-> f f ,a i-> d} is also a partial firing but not a simple firing, since 
z ^ fv(c — > a), therefore the firing is not mininal enough. 

Lemma 7 Let \\f\ and \j/2 be constraints defined for the simple logic. Then 

(Yi^SFA(\i/i)) A (Yi^SFAiYi)) = (Vi A V2) a (SFA(yi A V2)) 

The equivalence between the left and the right hand formula; mean that they have the same solutions 
according to the simple satisfaction. 
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Proof. Let sols(i//) denote the set of solutions of y according to the simple satisfaction relation, and let 
sols(VAx) = Si, sols(i/A 2 ) = S 2 , so\s(SFA(yi)) = Sfi, and soIs(SFA(va 2 )) = S F2 . The proof follows from 
the expansion of the definition of simple satisfaction. 

sols((ViASFA(vi)) A (i/a 2 aSFA(^ 2 ))) 
= {cti u a 2 1 o\ g Si n Sfi , a 2 g S 2 n S f2 , o\ a 2 } 
= {cji ua 2 1 oi g Si,cri g Sfi,a 2 g S 2 ,a 2 g Sp 2 ,ai - a 2 } 
= {cji u a 2 1 <ti g Si , a 2 g S 2 , ai ^ a 2 } n {<Ji u a 2 1 o x g S Fi , a 2 g S F2 , ai — a 2 } 
= solsOi Ay 2 ) n soIs(SFA(vai) AS j FA(i/a 2 )) 
= sols((v^iA^2) A (SFA(vai)ASFA(va 2 ))) 
= sols((yi A y 2 ) a (SFA(yi A V2))) 

□ 

Lemma 8 (Partial to Simple) 

• If o, J \= P Y and MFA(a), then there exists a* such that a* C a and a 4 , J \= s \l/ s ASFA(\j/). 

• If a, J =\p Y and MFA(a), then there exists a* such that a* C a and C*,J? =\ s ¥ S ASFA(y). 
Proof. Proof is by straightforward induction on y. Note that A cannot occur in y, and in each step a* 
is guaranteed to exist and to obey the simple flow axiom: 

Case tt — a* = 0. 

Casex — a* = {x ^ a(x)}. 

Case Yi^¥2 — For the \= P case: Assume that a, J \= P \\f\ A \j/ 2 and MFA(a). Therefore a, J \= P \\f\ 
and a, J \=p \j/2- By the induction hypothesis, we have a\ C ai and <r| C a 2 such that af,y |=s 
\I^ASFA(xifi) and of, i/a|aSFA(^ 2 ). Clearly we have of - of and afua^ C a, and by 
Lemma 7 we conclude that af U cr| , J \= s (yi A y/^ASFA^i Aift). 

For the =|p case: Assume that a, =|p y/"i A y/2 and MFA(a). Therefore a, |=p or a, ^p 
i/a 2 . By the induction hypothesis, we have of C ai and of C a 2 such that of, ^5 i//f aSFA(i//i) 
and of , |= 5 y/f aSFA(i^ 2 ). Note that A is in a negative position, therefore (y\ /\\l/ 2 ) S = ¥i^¥2- 
Clearly we have that when a* = of or a* = of, a*, J =\$ A 1//2) 5 a SFA( i/^i A 1/^2) and a* C a. 
Case -ityA — by induction hypothesis. 

Case p(t\,. . .,t n ) — in both cases a* = {v i-> a(v) | v Efv(p(t\,. . . A))} 

□ 

Lemma 9 If \=s ¥> tnen ® F \ \=p ¥ P - =\s ¥> tnen ° f \ ^ =\p ¥ ? - 

Proof. By straightforward induction on y. □ 
Lemma 10 (Simple to Partial) If a is a simple firing for then o p is a partial firing for \j/ p . Fur- 
thermore, for all a' such that G p C a' and o' satisfies the meta-flow axiom, o' is a partial firing for 
¥ P - 

Proof. Follows from Lemmas 4 and 9. □ 

The key difference between simple and partial is that simple finds the kernel of a solution by exam- 
ining only the relevant variables. All partial solutions can be reconstructed by filling in arbitrary values 
(satisfying the meta-flow axiom) for the unspecified variables. Note that the classical model is faithful 
to existing semantics of Reo. By shifting to a partial logic, we can model pure synchronisation, which 
is when a synchronisation variable is true and the corresponding data flow variable is _L. In the simple 
logic, if the data flow variable is not mentioned, it will never be assigned a value, reflecting that there is 
no data flowing in the corresponding ports, i.e., it is a pure synchronisation port. 
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5 Locality 

With simple logic, there is still a single set of constraints and thus it is not clear how to exploit this to 
extract any inherent concurrency nor is it clear how to partition the constraints to distribute them. Our 
motivation is to use (distributed) constraint satisfaction as the basis of a coordination language between 
geographically distributed components and services. 

The local semantics is based on a configuration consisting of constraints partitioned into blocks of 
constraints, denoted by *P = , ■ ■ ■ , (Wn), or simply *P = (\j/i) ieL ' n - 

Definition 8 (No-Flow Assignment) An assignment a is called a no-flow assignment whenever dom(a) 
C X and for all x G dom(a) we have a(x) = f f . <l 

Axiom 3 (No-Flow Axiom) We say that a constraint y obeys the no-flow axiom whenever there is some 
no-flow assingment a with dom(a) ^jv{y) n SC such that a, J? \=s y. 

A configuration *F = obeys the no-flow axiom iff each obeys the no-flow axiom. 

From now on, we assume that all configurations satisfy the no-flow axiom. 

Definition 9 (Boundary) Given a configuration *F = (tyi), . ■ . , (Yn)> define boundary '\p((v^) ) asfv(\j/i) H 
jv(¥-i), where^-i = (y/i), (yj-i), (Vi+i), (V»)- 

We drop the *F subscript from boundary^ (— ) when it is clear from the context. <] 

Definition 10 (Local Firing) Given a configuration m = (yi) , • • • , (Wn)- We say that: 

• a is a local firing for a block ( !//;•) if and only if o is a simple firing for y/i and for all x G 
boundary^^Yi}) we have <J F (x) / tt — we call this the boundary condition. 3 

• o is a local firing for *P if and only if a = (Ti U • • • U a m i such that 

1. h,...,I m i,...,I m is a partition of { 1 . .n}; 

2. (pi = Aye/; V) where i G \..m; and 

3. Oi is a local firing for block (<p ( ) where i G l..m', <i 

The intuition behind this definition is: 

1 . a local firing can occur in some isolated block or the conjunction of some blocks or in independent 
(conjunctions of) blocks; and 

2. within each block a simple firing occurs that makes the assumption that there is no-flow on its 
boundary ports. 



a a 



( cdg 2 y 



Lossy i 



c c 
-► 



Lossy 2 




Merger ^ » ► [ Client ~] 



Figure 2: Simple network of constraints: two competing data producers. 



a is defined in Lemma 6. 
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Example 2 We introduce a small example in Figure 2 that we use to illustrate the definition of local 
firings. Let 0,-, where i € 1..6, be the constraints for CDG\, CDG2, Lossy lt Lossy 2 , Merger, and Client, 
respectively. We define 03 for Lossy j and 05 for Merger as follows. 

03 = b^af\b^{d=b) 

5 = e ^(p\jd) A ->(bAd) A b^(e = b) A d^(e = d) 

The remaining constraints can be derived similarly. 

The Lossy j cot arbitrary lose data flowing on a, or pass data from a to b; and Merger can pass data 
either from b to e or from d to e. The configuration that captures the behaviour of the full system is given 
by^ mei . ge = (^ASFA^)Y^- 6 . 

We present some simple firings for the Lossy primitive, and show which of these are also local 
firings for *F merge , and we then describe some more complex local firings for Emerge- We omit the 
formal proof that the conditions for local firings hold for these firings. Formula 03 can be written as 
-i(^A-ia) A-i(iA-i(a = b)), and the boundary of (03) is {a,d,b,b}. Valid simple firings for 03 are 
{b 1 ^ f f }, {a 1 ^ tt,b 1 ^ f f }, and {a i-> tt,a 1— > v,6 1— > v}, for any possible data value v G £Fa?a. The 
only simple firing that is also a local firing is then {b^ff}. This means that {b ^ f f } is also a local 

firing of merge- 

It is also possible to show that the solution o top corresponding to the flow of some data value v from 
CDGi to Client is a simple firing for 0i A 03 A 05 A 06, and that the solution O\, ottom corresponding to data 
being sent from CDG2 to Lossy 2 and being lost is a simple firing for 02 A 04. More precisely, we define 
®top = {a ^ tt,b 1 — ^ tt,d 1 — ^ ff ,e 1— > tt,a 1— > v,ft v,e 1— > v} and (Jbottom = {c ^ ff,d 1— > ff}. The 
boundary for both sets of primitives is just {c?}. In the solutions a top and Gbottom the value of J is never 
tt, so the boundary conditions hold. Therefore a top , Obottom, and a top U Obottom are also local firings of 

T merge ■ 

The local semantics is based on the simple semantics under the no-flow axiom assumption. Thus, a 
simple firing can be trivially seen as a local solution, but a local firing needs to be extended to be seen as 
a simple firing. This extension corresponds exactly to the unfolding of the no-flow axiom for the blocks 
of constraints not involved in the local firing. The embedding between these two semantics is formalised 
below. 

Lemma 11 (Simple to Local) If o is a simple firing for then a is a local firing for *P = (1//). 
Proof. As boundaryy,{{\y) ) = 0, a simple firing for y is also a local firing for y. □ 

Lemma 12 (Local to Simple) Let G be a local firing for = (yi) , . . . , ( y n ), then there exists a (J* such 
that(l) a C a*, (2) for all x G dom(a*) \dom(a) we have a*(x) = ff, and(3) a* is a simple firing for 

Aiel.,i¥i- 

Proof. Assume that a is a local firing for *F = (yi) , . . . , (y n ). Without loss of generality, we can 
assume that a = Oi U • • • U a m where (1) m < n and for each k G \..m we have that at is a local firing 
for (yk)- From the no-flow axiom, we can have a no-flow assignment aj for each jGm + l..n such that 
Oj, J' \=s yj. From the boundary condition, we can infer that for each o k and a J the condition o k ^ a J 
holds. Thus, for a* = a U (J ; - cj, we have a*, J \= s A, e i..n ¥i- □ 
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6 State 

6.1 State-machine 

We follow the encoding of stateful connectors presented by Clarke et al. [5]. To encode stateful connec- 
tors we add stcite p and state' p to the term variables, for each p G P corresponding to a stateful primitive. 
A state machine with states states q\,...,q n h encoded as a formula of the form: 

\j/ = state p = q\ — > \\f\ A . . . A state p = q n — ► \y n 

where . . . , y n are constraints representing the transitions from each state. For each firing a, the value 
of a(state' p ) determines how the connector evolves, giving the value of the next state. 

We illustrate this encoding by an example, presenting the constraints encoding the state machine of a 
FIFO\ buffer from Table 1. The state can be either empty or full(d), where d 6 S)ata, and empty and 
full are function symbols in ^ . We then define yz/b-constraint to be state^ = empty — ► y e A state -fifa = 
f ull(d) — ► Xj/f, where l/^ and \fff are the upper and lower labels of the following diagram, respectively: 



-^bha^t state' fif = f ull(o) 




-^aAb^b = dA state' ff () = empty- 



To complete the encoding, we add a formula describing the present state to the mix. In the example, the 
formula state ff = empty records the fact that the FIFOi is in the empty state, whereas state fif D = f ull(<f ) 
records that it is in the full state, containing data d. The full constraint for the FIFO\ primitive is now 
(refining the constraints in Table 1): 

statefif = empty — > y e A statefif () = f ull(<i) — ► Xjff A statefif a = empty, 
6.2 Constraint satisfaction-based engine 

A constraint satisfaction-based engine holds a configuration with the current set of constraints and op- 
erates in rounds, each of which consists of a solve phase and an update phase, which uses the firing to 
update the constraints and to model the transition to a new state. This is depicted in Figure 3. 




Figure 3: Phases of the constraint satisfaction-based engine. 

Each block of the configuration is a conjunction of two constraints (pAe), where p is persistent 
and £ is ephemeral. Persistent constraints are eternally true, and can be either (normal) stateless con- 
straints, stateful constraints, or the conjunction of persistent constraints. Ephemeral constraints describe 
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the present state of the stateful constraints. Configurations are updated at each round. Let J" be an in- 
terpretation and, for each i G \..n, let Pj be a (possibly empty) set of names of stateful constraints. A full 
round can be represented as follows, where the superscript indicates the round number: 

(p . A£ myel., solve^ {om) update^ ^ A £ „ +l yel..n 

satisfying the following: 



i€l..n 

g m+i = f\{state p = c m {state' p ) \ p £ Pi and c m {state' p ) / _L} A 
A{£, m \P^ p i and a m (state' p ) = _L} 



(update) 



In round m, the solve phase finds a solution a m , and the update phase replaces the definition of e m 
by £ m+1 for round m, whenever the variable state' is defined. A correctness result of this approach with 
respect to Reo, for the classical semantics, has been presented by Clarke et al. [5] . The authors use the 
constraint automata semantics for Reo [3] as the reference for comparison. The present approach adapts 
the previous one by accounting for partial solutions of the constraints, which means that only some of 
the state variables are updated. 



7 Interaction 

We now extend the model with means for external interaction. 



7.1 External functions, predicates and constraints 

We defined in § 3.2 a core syntax for logic formulas, extended with state variables in § 6. Satisfaction of 
formulas is defined with respect to an assignment a defining the values of variables, and an interpretation 
giving meaning to predicates. We now extend the syntax of the logic and the definition of interpreta- 
tion J* , by introducing new symbols whose interpretation is also given by J 1 . These symbols are external 
predicate symbols p G P, external function symbols f £ F, and external constraints c £ C. We also in- 
troduce communication variables k G K whose value in the solution of a round can be communicated to 
the outside world. Formula? are now given by the following syntax: 

Y ::= tt | x | yiAy/2 | I p(t) | p(T) | c{y,t) 
t ::= x | state p \ state p \ k | f(t) \ f(t) 

Use t as a shorthand for t\, . . . ,t n . We extend the definition of interpretation to be an arity-indexed 
family of partial map from P n x Z? n to {tt,ff }; from P„ x 2F n to {tt,ff }; from F„ x S? n to ground 
terms; and from C to a term with I formula? parameters and k term parameters. 

We also extend the Val a j function, which is now parameterized on a and . This function replaces 
variables v by a(v) and {(ti,...,t n ) by J^(f, Val a t jr, . . . , Val a or is undefined if any component is 
undefined. 
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The extension of the syntax of the logic requires the addition of two new (dis)satisf action rules: 

o,S\=sp(ti,...,t n ) iff Q(Val a ^(h),...,Val<j^(t n ))^tteJ 

and dom(a) =fv{p{t\ . . .,t„)) 
a, J \= s c(Yu---,Ym, h,...,t n ) iff o,J \= s Y[¥i/v\,---,¥m/v m ,ti/v m+ i,...,t m /v m+n \ 

where c i-> A(vi, . . . ,v m+n ).\j/ € J* 

(J,J?=\ s p(ti,...,t n ) iff p(Val ai s(ti),...,Val at s(t n ))t->ff€S 

and dom(a) =fv(p(t\ . . .,t n )) 
<j,j? =\ s c(Wi,---,Ym,ti,-.-,t n ) iff o, J =\ s YiVi/vi, ■ ■ ■ ,Wm/v m ,h/v m+ i, . . . ,t m /v m+n ] 

where ci->A(vi,...,v m+ „).V€ J 

The notation A (vi, . . . ,v n ).\j/ denotes that y is a formula where {vi, . . . ,v„} Qfv(y). Each v,- is a variable 
that acts as a placeholder for y, that is substituted when evaluating the external variable mapped to the 
A -term, hence the A -notation. 



7.2 External world 

The constraint-based engine introduced in § 6.2 describes the evolution of a configuration (a set of blocks 
of constraints). We now assume the existence of a set of primitives P, each of which provides a single 
block of constraints to the engine. These primitives can be one of three kinds [5] : 
internal, stateless denoted by P no . The underlying constraints involve neither state variables nor com- 
munication variables in K, and all constraints are persistent — represented by setting the ephemeral 
constraints to e p = tt, where p G P no . 

internal, stateful denoted by Pi nt . Such primitives have constraints over the state variable pair state p 
and state 1 p , where state p represents the value of the current state of p G Pi nt and state' p the value 
of the next state. The emphemeral constraint denotes the current state and is always of form e p = 
state p = t, for some ground term t. No communication variables may appear in the constraints. 

external denoted by P ext . Such primitives express constraints in terms of a communication variable k 
through which data is passed from a primitive p 6 P ext to the outside world. The outside world then 
sends a new set of constraints to represent p's next step behaviour. No state variables can appear 
in the constraints, as it is assumed that the state information is handled externally and incorporated 
into the constraints sent during the update phase. 
We assume that the constraints y p provided by each primitive p G P can only have a fixed set of 
free variables, denoted by fv{p). Note that jv(lj/ p ) Qfv(p). The relation between external symbols, 
communication variables and the external primitives in P ext is made via an ownership relation. That is, 
each external symbol and each communication variable is owned by a unique primitive in P ext . 

Definition 11 (Ownership) Let 6 = FUPUCUK. Each o 6 G is managed by exactly one p 6 P ext . 
This is denoted using function own : G — > P ext . We may write k p to indicate that own(k) = p. 

We write {y)q to indicate that the constraints in \j/ are owned by primitives Q, where Q C P. <\ 

Example 3 We extend the constraints of our running example from Table 1, presented in Table 2. Using 
the updated constraints from Table 2, the global constraint is given by the configuration (^,) !Gl " 7 , the 
synchronous variables are 3£ = {a,b,c}, the only uninterpreted predicate symbol is equality, more G C 
is an external constraint symbol, result G K is a communication variable, and UserAppr G P is an exter- 
nal predicate symbol. Furthermore, ow«(more) = CDG, ow«(result) = Client, and own (UserAppr) = 
User approval. 
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Primitive Constraint 

Xjfi = fl^(flA(fl = diVfl = d2Va = d3 Vmore(a))) 
y/2 = result = b 

y/3 = c->(cA UserAppr (c) ) 



Table 2: Updated (interactive) constraints of a set of primitives. 

The updated constraints in Table 2 illustrate the usage of the extensions to the logic. External con- 
straints can model on-the-fly constraint generation. The interpretation of more can refer to new external 
constraints, and this process can be repeated an unbounded number of times. Communication variables 
provide a mean to communicate the result to the external world, as the constraints of Client show, via 
the variable result. Finally, the external predicate UserAppr in Xfo illustrates the possibility of asking 
external primitives if some predicates hold for specific data values. 



( cdg y 

► [ Client ) 
J User approval 



Example of the execution of the engine Recall Example 2, which is based in a set of primitives P. 
We partition P into Q and R, where Q = {Client, CDG \,Lossy l , Merger}, and R = {CDG2,Lo^ 2 }- To 
provide a better understanding of how the engine evolves with respect to the external interaction, we 
present a possible trace of the evolution of the constraints. The relation — denotes the evolution of the 
constraints by either applying transformations that preserve the set of possible solutions, or by extending 
the interpretation Jf based on external interaction. The initial persistent and ephemeral constraints of 
each primitive p G P are denoted by p p and e p , respectively. As in Example 2, 0,-, where i € 1..6, are the 
constraints for CDGi, CDG2, Lossy l , Lossy 2 , Merger, and Client, respectively. 



PCDG! 


= SFA(a) 




= h 


P 'Lossy ] 


= fo7\SFA(a,b) 




= tt 


PCDG 2 


= SFA(c) 


£CDG 2 


= 02 


PLossy 2 


= (j> 4 ASFA{c,d) 


^Lossy 2 


= tt 


PClient 


= (j) 6 ASFA(e) 


^Client 


= tt 


pMerger 


= <t> 5 ASFA(b,d,e) 


^Merger 


= tt 



The initial configuration of the system is given by the set (p p Ae p ) p eP . We write £ p to denote the 
ephemeral constraint of p in round n. During the execution of the engine, both the constraints and 
the interpretation changes during the solving stage, which we make explicit by using a pair with the 
interpretation and the constraints. The evolution of a possible trace for our example and its explanation 
follows: 

^,(p P ^e p )f p 

-** A </) 3 A0 5 A<j> 6 ASFA({a,b,d,e})) Q ,(<l>2A<i>4ASFA({c,d})) R 

->■* J , ((aAbAeAmore(a)Ab = aAe = b A result = e) Y V / ?)g> {{cAc = d 2 A^d) Y Yr)R 

->■* J ', ((a Ab Ae Amore(a) Ab = a Ae = b Aresult = e) Y Yq)Q: (p r Ae^)' r eR 

—>* J' , ((aAfcAeAa = d 4 Aevenmore(a)A£ = aAe = &Aresult = e) Y y q )Q, 
( Pr AS^ R 

->■* J' , ((aA6A<?Aa = d 4 AS = d4Ae = d 4 Aresult = d4) Y Y q ) Q , (p r AS?) r r eR 
->* J?,{p q AEt)f Q ,{p r AE^ R 
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We now look in more detail into each of the transitions applied above. 

1. The blocks of constraints are joined into two blocks based on the partition Q and R (of P). The 
persistent and ephemeral constraints are replaced by their definitions. The constraints inside each 
new block are manipulated following traditional constraint solving techniques until we obtain a 
disjunction of cases. We then focus on one specific disjunct in each block. 

2. The block tagged with/? (in the last step of (1)) has a trivial solution {cm tt,d i— > f f ,ci— ► d 2 } that 
does not cause any state change. As the boundary conditions hold (d / tt), we can perform the 
update phase on this block. Hereafter the individual blocks for each primitive r G R are restored, 
updating the ephemeral constraints to £;?. In this case there is no state change, i.e., = e}. 

3. Interaction with the external world is performed to extend the interpretation for more, obtaining 
</' = J' U {more m> A(v).(v = d 4 V evenmore(v))}. External predicate more(o) is replaced by 
its new interpretation, and the manipulation of the constraints continues as in (1), until we find a 
new conjunction for the first block which satisfies the trivial solution. 

4. In the last step the update phase is performed on the first block. Note that the trivial solution obeys 
the boundary conditions (d / tt). The individual blocks for each primitive q G Q are restored, 
using the corresponding persistent constraints and the new ephemeral constraints for round 2. In 
this case the ephemeral constraint for the primitive CDGi is updated, while the other primitives 
in Q keep the same ephemeral constraints. The update of the constraints of CDGi is performed 
by querying the external primitive CDGi for its new ephemeral constraints, providing the value of 
the communication variable of CDGi (result = d 4 ). We call this new constraint £c DGr After the 
update, the interpretation "forgets" the value of more and is reset to J 1 . 

We leave for future work the formalisation of the rules that describe the evolution of the constraints and 
the interpretation during the constraint solving process. 

7.3 Discussion 

Local firings can be discovered concurrently. Furthermore, the explicit connection introduced by the 
ownership relation, from blocks of constraints and external symbols to external primitives, paves the 
way for constraint-solving techniques that interact with the external world while searching for solutions 
for constraints (concurrently). We start by discussing some of our motivation to introduce the local 
satisfaction relation, and we then explore some more details of our proposed interactive engine. 

Why locality? 

Some of the inspiration for developing a semantic framework that takes into account locality aspects of 
a model that requires global synchronisation came from experiments undertaken during the development 
of a distributed implementation of Reo. 4 This implementation is incorporated in the Eclipse Coordi- 
nation Tools, and its distributed entities roughly correspond to primitives in our constraint approach. 
There we also make a similar distinction between the two phases of the engine. While developing the 
distributed engine, we realised the following useful property of the FIFOi channels: in each round it is 
sufficient to consider the two halves of a FIFO independently. This property went against the implicit 
globality assumption in current Reo models, and was never clearly exploited by Reo. This locality prop- 
erty becomes particularly relevant in the extreme case of a Reo connector consisting of several FIFOi 



4 http: //reo .project . cwi.nl/cgi-bin/trac . cgi/reo/wiki/Tools#DistributedReoEngine 
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channels are composed sequentially. In the communication between any two FIFO's from this sequence, 
traditional Reo models require all the FIFO's to agree, while our distributed implementation requires 
only the agreement of the two FIFO's involved in the communication. 

In more complex Reo connectors, such as the multiple merger, 5 it is possible to see that most of 
the steps involve only the flow on a small part of the connector. It is also possible to find islands of 
synchronous regions, with FIFO channels in the boundaries, where our boundary condition holds for the 
possible solutions. The approach described in this paper not only justifies the correctness of the locality 
obtained by the FIFOi channels, but it also generalises it to arbitrary solutions where the boundary 
conditions hold on the boundaries of the synchronous region. 



Interactive engine 

We now explore some characteristics of the engine described in § 6.2, using the logic with external 
symbols introduced in § 7.1. We assume that the interpretation is initially empty regarding external 
symbols. During the solve stage, Jf is extended every time the external world provides new information 
about these external symbols. Similarly, the engine can request for the interpretation of specific symbols 
whenever these are required to find solution. The communication variables play a similar role to state 
variables. Instead of being directly used in the next round, their value is sent to the primitive that owns 
the variable, and the engine waits for new (ephemeral) constraints from that primitive. These constraints 
are then used in the next round. 
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Figure 4: Interaction with Reo components (left) and with our view of components (right). 



The interaction between components and the engine differs in our model with respect to other de- 
scriptions of Reo, in that the components play a more active role in the coordination, as depicted in 
Figure 4. The usual execution of Reo [2] is also divided in two main steps, but the interaction is more 
restricted in previous models of Reo. In the solve stage the components attempt to write or take a data 
value. In the update stage the engine requests or sends data values, and restarts the solve stage. In our 
model we blur the distinction between connectors and components. During the solve stage components 
can provide constraints with external symbols, that will only be prompted by the engine as required. 
During the update stage the engine sends the components the values of their communication variables, if 
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defined, and waits for their new constraints for the next round. Our approach therefore offers components 
the ability to play a more active and dynamic role during the coordination. 

8 Conclusion and related work 

Despite Wegner's interesting perspective on coordination as constrained interaction [16], little work takes 
this perspective literally, representing coordination as constraints. Montanari and Rossi express coordi- 
nation as a constraint satisfaction problem, in a similar and general way [13]. They view networks as 
graphs, and use the tile model to distinguish between synchronisation and sequential composition of the 
coordination pieces. In our approach, we explore a more concrete coordination model, which not only 
captures the semantics of the Reo coordination language [1], but also extends it with a refined notion of 
locality and a variety of notions of external interaction not found in Montanari and Rossi's work. 

Minsky and Ungureanu took a practical approach and introduced the Law-Governed Interaction 
(LGI) mechanism [12], implemented by the Moses toolkit. The mechanism targets distributed coordina- 
tion of heterogeneous agents, enforcing laws that are defined using constraints in a Prolog-like language. 
The main innovation is the enforcement of laws by certified controllers that are not centralised. Their 
laws, as opposed to our approach, are not global, allowing them to achieve good performance, while 
compromising the scope of the constraints. Our approach can express constraints globally, but can solve 
them locally where possible. 

In the context of the Reo coordination language, Lazovik et al. [10] provide a choreography frame- 
work for web services based on Reo, where they use constraints to solve a coordination problem. This 
work is an example of a concrete application of constraints to coordination, using a centralised and non- 
compositional approach. We formalised and extended their ideas in our work on Deconstructing Reo [5]. 
The analogy between Reo constraints and constraint solving problems is also pursued by Kliippelholz 
and Baier [9], who describe a symbolic model checking for Reo, and by Maraikar et al. [1 1], who present 
a service composition platform based on Reo using a mashup's data-centric approach. The latter can be 
seen as an scenario where constraint solving techniques are used for executing a Reo-based connector. 

One of the main novelties with respect to our previous work [5] is the introduction of a partial seman- 
tics to the logic, and techniques for exploiting this semantics. Partiality favours solutions that address 
only a relevant subset of variables, and can furthermore capture solutions in only part of a network, 
which cannot be considered independently in a classical setting. Other applications of partial or 3-valued 
logic exist [4, 8], and model checking and SAT-based algorithms exist for such logics. We do not ad- 
dress verification of partially defined systems, but instead we focus on the specification and execution 
of these systems. Verification of systems specified by a partial logic would require to assume a fixed 
interpretation of external symbols, but still presents an interesting challenge, which is out of the scope 
of this paper. Note that the constraint solving of our partial logic is different from the partial constraint 
satisfaction problem (PCSP) [7], which consists of finding solutions satisfying a constraint problem P 
that are as close as possible to the original problem, although they may be different in most cases. 

Faltings et al. [6] explore interactive constraint satisfaction, which bears some similarity to our ap- 
proach. They present a framework of open constraint satisfaction in a distributed environment, where 
constraints can be added on-the-fly. They also consider weighted constraints to find optimal solutions. 
In this paper we do not explore strategies to make the constraint solving process more efficient, such 
as considering the order in which the rules should be applied. The main differences between our work 
and theirs are that we focus on the coordination of third parties, making a clear distinction between 
computation and coordination, we use a partial logic, and we have more modes of interaction. 
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CRIME (Consistent Reasoning in a Mobile Environment) is an implementation of the Fact Space 
Model [14], which addresses highly interactive programs in a constantly changing environment. Appli- 
cations publish their facts in a. federated fact space, which is a tuple space shared by nearby devices. 
Each fact is defined as a Prolog-like constraint, and the federated fact space evolves as other applications 
connect or disconnect. The resulting system is a set of reactive objects whose topology is constantly 
changing. Many of the fact space model ideas are orthogonal to the interaction constraints described in 
this paper, and its implementation could form a possible base platform for our approach. 

Conclusion 

The key contributions of our work are the use of a local logic which does not require all constraints to be 
satisfied, and the different modes of interaction. Together these enable more concurrency, more flexibil- 
ity, and more scalability, providing a solid theoretical basis for constraint satisfaction-based coordination 
models. Furthermore, constraints provide a flexible framework in which it may be possible to combine 
other constraint based notions, such as service-level agreements. As future work we plan to explore the 
extension of Reo-based tools, and to implement an interactive and iterative constraint-solving process 
based on the logic described in this paper. In the process, we will introduce rules describing how to 
manipulate blocks of constraints that preserve simple solutions, in order to describe in more detail the 
concurrent search for local firings. Later we plan to explore strategies for the application of these rules, 
and to understand better the efficiency of our approach. 
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